1. Field of the Invention
The present invention relates to computer-executable procedures, and, more particularly, to construction of computer-executable procedures using examples.
2. Description of the Related Art
A common use of computer systems is the execution of procedures. As used herein, the term “procedure” refers to a collection of computer-executable operations (i.e., any transformation of data or of visible appearance of the screen) that satisfy the following constraints:
(1) A procedure has a specific goal.
(2) The procedure is performed by an individual at different points in time or is performed at least once by a number of individuals.
(3) The procedure can have a limited amount of “structural” variability.
(4) Individual steps of a procedure can have a limited amount of variability, and can be performed on different objects in different instantiations of the procedure.
It is clear that a specific task such as copying a specific file from a directory to another is generally not a “procedure” unless the task is either repeatedly performed by the same individual or commonly performed by a variety of individuals. Similarly, answering electronic mail, writing a technical paper, debugging a program, playing a video game, and the like, do not fall under the definition of “procedure” as described above because such activities have (1) generic rather than specific goals, (2) very high structural variability, and (3) very high variability of individual steps.
Tasks such as scheduling a meeting (e.g., reserving a a conference room and the appropriate audio/visual equipment, sending notes to the invited people, and requesting refreshments), submitting a travel request, requesting a clearance for a publication, and requesting reimbursement for miscellaneous expenses are “procedures,” as defined above, because they (1) have a well-defined, narrow goal, (2) are commonly performed in the same manner by multiple individuals across an organization, (3) have limited structural variability, and (4) have limited variability of individual steps, although some details may vary across different executions of the same procedure (e.g., the date of a meeting, the list of invited people, and the quantity of refreshments may be variable in scheduling a meeting).
Other tasks that fall under the aforementioned definition of “procedure” include installing and upgrading software applications, troubleshooting a specific computer system problem (e.g., fixing a network card of a portable computer), configuring a software installation, and tuning a collection of applications to achieve a desired goal (e.g., configuring a database system to minimize the response time to specific types of transactions). A simple test to determine whether a task falls under the aforementioned definition of “procedure” is as follows: If it is possible with current technology to write a program that executes a desired task with limited intervention of the user and the desired task is commonly performed, then the desired task is a procedure; otherwise, it is not.
It should be noted that software applications are designed to provide functionalities to perform specific steps of a procedure, rather than the procedure as a whole. Accordingly, a procedure may be performed by one or more software applications.
When a procedure is performed by a sufficiently large number of users, the procedure is commonly coded as a computer program—either using a traditional programming language (e.g., Java, C++) or a scripting language (e.g., Perl). This is the case, for example, for installing software applications or installing/configuring hardware devices. The limitation of this approach, however, is a high cost of developing, testing, and maintaining a program for each procedure. Therefore, typically only selected, well-understood procedures intended for a wide audience are actually encoded as a programs.
At the other end of the spectrum, individual users can rely on macro recorders to perform repetitive tasks. A macro recorder is a computer program that remembers a sequence of actions performed by a user and is capable of repeating the sequence. Macro recorders may exist as a part of software applications (e.g., free editor EMACS (Editing MACroS) generally have a built-in macro recorder), in which case they are limited to recording and repeating operations performed within the application to which they belong. Macro recorders may also exist as standalone programs that interact with the GUI (Graphical User Interface) of other applications of the OS (Operating System). The main limitation of macro recorders is that they execute verbatim the same operations that are recorded. That is, they are unable to abstract from the specific observed steps to generic operations (i.e., macro recorders are unable to “generalize”).
Because macro recorders do not generalize, they can rarely be used to encode executable procedures that can be disseminated widely. That is, the small differences in how individual computers are configured make recorded macro extremely brittle and error prone.